Bump @playwright/test from 1.61.1 to 1.64.0 in the tests-playwright group across 1 directory - #622

Update dependabot.yml file.

Captures the brainstormed design for a GitHub Actions workflow that opens
draft PRs to update package.json gutenberg.sha for trunk (latest public
release) and the most recent version branch (daily, from wp/X.Y head).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…kflow.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…decouple trunk job.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…spatch for Gutenberg Sync.

- Remove the dry_run input and all DRY_RUN handling.
- Replace the auto-detecting setup job with a workflow-level
  CURRENTLY_SUPPORTED_BRANCH env var (mirrors test-old-branches.yml).
- Replace the target choice input with a free-form branch input accepting
  "trunk" or an X.Y branch name; scheduled runs update trunk plus the
  currently supported branch, while a manual run targets one branch.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… env vars.

Define BASE_BRANCH and HEAD_BRANCH as workflow-level environment variables
derived from the branch input, and remove the explicit determine/validate
step. An invalid branch now fails at the checkout step, which is sufficient.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…upstream.

WordPress/wordpress-develop does not accept pushed branches, so the workflow
now runs from a fork:

- Guard inverted to run only on forks (github.repository != upstream).
- Check out the target branch from upstream so the PR is built on current
  content, push the gutenberg-sync/<branch> branch to the fork, and open the
  pull request from the fork branch back to upstream.
- Drop the canonical-only GitHub App token (its private key cannot live on a
  fork). Push with the built-in GITHUB_TOKEN; open/label the upstream PR with
  an optional GUTENBERG_SYNC_TOKEN PAT. Without the PAT, the branch is still
  pushed and the run prints a link to open the PR manually.
- Skip creating a duplicate when an open Gutenberg Sync PR already exists for
  the target branch from another fork.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…he wp/X.Y existence check.

- Replace the manual git clone of WordPress/gutenberg with an actions/checkout
  step (fetch-depth: 0 so the changelog's git log range has history), and read
  the new SHA from the checked-out head.
- Remove the custom "wp/<branch> does not exist" guard; if the branch is
  missing, the Gutenberg checkout fails on its own, which is sufficient.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…mplate.

Move the PR body structure into .github/workflows/gutenberg-sync-pr-body.md
with __BRANCH__, __NEW_SHA__, __SOURCE_LINE__, and __CHANGELOG__ placeholders.
The resolve steps now only emit the scalar values and write the changelog
content to a file; a single awk step renders the template (inserting the
changelog file verbatim so untrusted release notes are never re-substituted).
The template is sparse-checked-out from the workflow's own ref so it is always
available and version-matched.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…beling.

- Render the PR body by writing each placeholder into a working copy of the
  template as its value is resolved (sed for scalars, awk to insert the
  changelog verbatim). This removes the SOURCE_LINE environment variable and
  the separate body-building step.
- Stop applying the label in the sync workflow and identify an existing PR by
  the gutenberg-sync/<branch> head branch name instead of the label.
- Add gutenberg-sync-label.yml: on pull_request_target (opened/reopened) it
  labels any gutenberg-sync/* PR using upstream's token, which (unlike the
  fork's token) can label PRs on upstream. It never checks out PR code, so the
  pull_request_target trigger is safe (zizmor ignore documented inline).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… the template.

- Move the body template to .github/template-gutenberg-sync-pr-body.md.
- Break each resolve path into one action per step (copy template, fill each
  placeholder, retrieve release details / determine SHAs, build changelog).
- Break the push into create-branch, update-file, stage, commit, add-remote,
  and push steps.
- Split the pull request step into lookup, update-existing, and open-new.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…n-branch jobs.

Gate the branch selection at the job level (inputs.branch == 'trunk' vs
!= 'trunk') so the per-step branch conditionals are no longer needed. Each job
runs end to end: checkout, resolve, push to the fork, and open/update the PR.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…sable workflow.

Add reusable-gutenberg-sync-pr.yml (workflow_call) that pushes the
gutenberg-sync/<branch> branch to the fork and opens or updates the upstream
pull request. The trunk and version-branch jobs now only resolve the new SHA,
title, and body (uploaded as an artifact) and expose them as outputs; the
open-pull-request job calls the reusable workflow with those values. This
removes the push/PR steps that were duplicated across the two jobs.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ranch conditions.

Remove the reusable-gutenberg-sync-pr.yml workflow and the resolve/publish job
split, returning to one sync job whose trunk- and version-specific steps are
gated with inputs.branch conditions.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…y instead of opening a PR.

The compare link cannot carry the generated body, so stop creating/updating the
pull request (and drop the GUTENBERG_SYNC_TOKEN PAT). The workflow now pushes the
branch to the fork and writes the PR title and body to the job summary, with the
body in a fenced block for copy/paste into a manually opened pull request.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The reorganized workflow split resolve, body-building, and push into separate
jobs, but the data did not cross the job boundaries. Fix that:

- Expose research's resolved values (new/old SHA, title, tag, release URL,
  proceed) as job outputs and consume them downstream via needs.research.outputs.
- Gate build-pr-body and create-update-branch at the job level on the proceed
  output instead of the per-step env.PROCEED checks, which were empty in those
  jobs.
- Pass the changelog between jobs as an artifact.
- Reorder research so the changelog is built after the SHAs are determined.
- Build the PR body template from the fork (sparse checkout) and fix the
  pr_body.md filename and the missing changelog insertion for version branches.
- Correct the create-update-branch permission (contents: write) and scope the
  read-only jobs to contents: read.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…a details block, and fix the SHA placeholder.

- Add a list of changes (git log --reverse OLD..NEW, linkified) to every PR
  body, right after the intro line. Trunk now also checks out Gutenberg (at the
  release tag) so the list can be built, and the new SHA is read uniformly via
  git rev-parse.
- For trunk, extract only the release's "## Changelog" section (which drops the
  heading and the First-time contributors/Contributors sections) and place it in
  a collapsed <details> labeled "Changelog"; remove the "## Changes" heading.
- Pass the commit list and release changelog between jobs as artifacts.
- Fix the __NEW_SHA__ replacement by giving the step its NEW_SHA env value.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… sections.

- Add a step to substitute the new __OLD_SHA__ placeholder.
- Rename the first details summary to "Changes" (it holds the commit list and
  source link); the second remains "Changelog" for the release notes.
- For version branches, remove the entire changelog <details> block rather than
  just the placeholder line, so the body has no empty collapsible.
- Insert the release changelog directly now that the template supplies the
  <details> wrapper.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ping.

- Update the pull request titles and job-summary headings.
- Escape the backticks in the PR titles so the shell treats them as literal
  text instead of command substitution (which blanked the code references).
- Restore the blank lines around __CHANGELOG__ in the template so the release
  changelog renders as Markdown inside the <details> block.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…e branch input.

- Run the single Gutenberg checkout for both trunk and version branches, after
  the release details are retrieved (so the trunk ref resolves to the release
  tag), and target wp/X.Y for version branches.
- Make the branch input a choice so only allowed values can be dispatched.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>